Debugging code is rarely an easy part of programming. Debugging programs (“debuggers”) have been around a long time, especially as used with compiled languages. Older generation debuggers allowed a programmer to sometimes set breakpoints to stop execution, and examine values of one or more variables, or even perhaps the call stack of the program. One of the features of some modern debuggers is that they can point the programmer to a line in source code where execution ceased or was paused. That way, a programmer is able to at least narrow the focus of an error and attempt to find the problem. With visual debuggers, the corresponding position in the source code is sometimes highlighted or otherwise given emphasis, so that the programmer can have context while debugging. This feature is particularly apparent in Interactive Development Environments (“IDEs”) such as Eclipse, where a graphical user interface (a “GUI”) commands and integrates many programming tasks, from editing, to compiling, to testing code. Debuggers are typically able to lead a programmer to a corresponding location in source code when the parser of the language produces some form of data structure that is cross-referenced to the source code.
In compiled languages, many compilers support compile-time flags for generating symbolic information that can be used by a debugger invoked at some later time to process the code. For example, using compile-time flags, source code line numbers can be inserted into the produced code so that they become part of the available information of a parse tree and/or the produced object code or bytecode. That way, when a parse tree is constructed and then evaluated by a debugger, the debugger can “walk” down the parse tree and still be able to determine what source code language statement corresponds to the parse tree node where execution was stopped. Of course, nothing comes without a price. Here, execution speed is typically traded for inserting such symbolic information, and execution speed often suffers when compile-time debugging flags are used to produce executable code. Thus, the code used for debugging is rarely the same code as that released to production.
In contrast to compiled code, debugging code that is written in an interpreted language poses a challenge. Interpreted language environments are often used for fast prototyping and in situations where dynamic responses are at a premium. Execution speed is paramount in such uses—customers would be unhappy if an expression to be evaluated was sent to the language interpreter and it took minutes to respond. Some interpreters generate intermediate code and bytecode which are then evaluated by a bytecode virtual machine. However, often, interpreted code is directly parsed and evaluated immediately, with simply a result remaining. Thus, generating information that can be used by a debugger while evaluating an expression in an interpreted language is difficult, and primitive commands such as examination of the call stack are typically what are provided.
Currently for debugging the S-PLUS® language, command-line antiquated (non visual) debugging is performed through the use of specific commands. For example, programmers can insert “cat” or “print” statements at specific spots within their programs to generate output statements at crucial locations, such as to print a value of a variable or a return value of a function. Such statements require a lot of forethought, are cumbersome to create, and may lead to accidental debug code left in place. Other commands are available to trace the call stack and/or to examine values after an error has occurred. Thus, commands such as “trace( )” and “try( )” provide a kind of “post-mortem” debugger and not prospective or dynamic debugging that occurs while code is being executed. Limited capability is available through the inspect( ) command, which allows a programmer to step through execution of a function, expression by expression, permits limited breakpoint (“mark”) support, but doesn't support placing arbitrary breakpoints in the code. Also, limited capability is available by inserting a browser( ) command in the source code directly, which causes execution to pause, but no further step debugging is supported—information regarding location is provided.
FIG. 1 is an example screen display of using printing statements to debug a function. In FIG. 1, a function that computes the Fibonacci series of a given number has been defined in an S-PLUS® script 101. Two debug statements 103 and 104 have been added to the code to give information to the programmer. The result of executing the function defined in script 101 is shown in Console View 102. As can be seen by the output 105, debugging this way is cumbersome, can generate long output (especially if this was executed on a more complex statistical function) and can be difficult to work through.
Note that S-PLUS is a registered U.S. trademark of Insightful Corporation, whether or not expressed herein in conjunction with the “®” symbol.